[Fix/#128] 사물함 신청 모집 기간 검증 추가 - #130

#️⃣연관된 이슈

• Closes 사물함 신청 시 모집 기간 검증 추가 #128
• 스택: [Feat/#119] 사물함 운영 회차 관리자 API 추가 #129(사물함 운영 회차 관리자 API 추가 #119, 사물함 운영 회차 관리자 API) 위에 쌓았습니다. #129가 머지되면 base를 main으로 바꿉니다
• 관련: 행사·사물함·반납 예약 알림 발송 #116(PR [Feat/#116] 행사·사물함·반납 예약 알림 발송 #121)이 한계로 적은 "사물함 신청 API는 apply_end_at을 확인하지 않는다"를 닫습니다

🎯 해결하려는 문제가 무엇인가요?

학생이 사물함을 신청할 때 서버가 모집 기간을 확인하지 않습니다. LockerApplicationServiceImpl.apply가 보는 건 "게시된 회차인가"와 "선택 가능한 사물함인가" 둘뿐이라, 모집 시작 전이나 마감된 뒤에도 신청이 들어갑니다.

LockerPeriod의 applyStartAt·applyEndAt은 지금 엔티티 매핑 말고는 읽는 곳이 한 곳도 없습니다.

❓ 왜 해결해야 하나요?

지금은 마감이 운영진 손에 달려 있습니다. apply_end_at이 지나도 누군가 게시를 내리기 전까지 신청이 열려 있고, 그 사이 들어온 신청은 유효하게 남습니다.

사물함은 선착순 즉시 배정이라 피해가 바로 생깁니다. 마감 후 신청이 다른 학생이 못 가져간 자리를 차지하고, 신청 취소 기능이 없어 되돌리려면 DB를 직접 고쳐야 합니다.

게시는 모집 시작 전에 미리 켜는 게 자연스럽습니다("곧 시작합니다"를 보여주려고). 그 상태에서 API를 직접 부르면 시작 전에 먼저 집어갈 수 있습니다.

같은 모듈의 행사 신청은 이미 막고 있습니다. EventApplicationServiceImpl.getOpenEvent가 calculateRecruitStatus(now, appliedCount)로 기간과 정원을 보고 ALREADY_CLOSED를 던집니다. 사물함만 빠져 있었습니다.

⭐ 어떻게 해결했나요?

행사와 같은 모양으로, 회차를 읽은 직후 모집 기간을 봅니다.

• LockerPeriod.isApplyOpen(LocalDateTime now) — 신청 시작 일시부터 마감 일시까지 양 끝 포함
• LockerApplicationServiceImpl.apply에서 requireApplyOpen(period) 호출
• LockerErrorCode.LOCKER_APPLY_NOT_OPEN (409)

사용 기간은 보지 않습니다. 사용을 시작한 뒤 남은 자리를 추가 모집하려고 마감 일시를 늘리는 운영이 있어 두 기간이 겹칠 수 있습니다. #129의 등록·수정도 같은 기준입니다.

🧩 이 PR의 한계 & 트레이드오프

• 시작 전과 마감 후를 한 에러 코드로 묶었습니다. 학생 화면에선 어차피 "신청할 수 없다"라 LOCKER_APPLY_NOT_OPEN 하나로 갔습니다. 행사도 ALREADY_CLOSED 하나로 처리합니다. 나누려면 ..._NOT_STARTED/..._CLOSED 둘이 됩니다
• 새 거절 케이스 테스트는 넣지 않았습니다. AGENTS.md 원칙에 따랐습니다. 기존 신청 거절 중첩 클래스에 한 건 추가할 자리는 있습니다
• 마감 연장은 #129의 수정 API로 합니다. [Feat/#119] 사물함 운영 회차 관리자 API 추가 #129 없이 이것만 들어가면 마감 연장이 DB 직접 수정이 되므로, 스택 순서를 지켜 주세요

⛓️ 기존 기능에 미치는 영향

• 학생 앱 동작이 바뀝니다. 지금까지 통과하던 "모집 기간 밖 신청"이 409로 막힙니다. 이게 이 PR의 목적이지만, 운영 중이라면 알고 있어야 하는 변경입니다
• 기존 테스트 6건의 픽스처를 고쳤습니다. 모집 기간이 2026-08-20 ~ 08-25로 고정돼 있어 지금은 마감 상태입니다. 어떤 고정 날짜를 넣어도 언젠가 깨지므로 현재 시각 기준(now ± 5일)으로 바꿨습니다. 테스트가 옛 동작(기간 무시)을 박아두고 있던 것이지 버그는 아닙니다
• 관리자 API와 구역·사물함 조회는 영향 없습니다

🔀 Edge Case & 실패 시나리오

📋 검토한 대안과 선택 이유

• 게시 여부로만 막기(현행 유지): 마감이 운영진의 수동 조작에 달려 있고, 선착순 자원이라 몇 시간의 틈이 실제 피해가 됩니다
• is_published를 신청 개폐 레버로 계속 쓰기: #129가 등록 시 true로 고정하면서 그 레버가 없어집니다. 마감은 시각이 정하는 쪽이 맞습니다
• 에러 코드를 400으로: 입력이 틀린 게 아니라 현재 상태와 충돌이라 409로 뒀습니다

💬 리뷰 포인트

• [c] 시작 전/마감 후를 한 코드로 묶은 것 — 앱에서 문구를 나눠야 하면 쪼개겠습니다
• [c] 테스트 픽스처를 현재 시각 기준으로 바꾼 것 — 고정 날짜를 유지하면서 거는 방법이 있다면
• [a] 신청 거절 테스트 한 건 추가 여부

검증 범위

compileJava·compileTestJava, :core:domain:event:test(121건), :infrastructure:db:test(Testcontainers) 통과했습니다.